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MODULE DE SECURITE COMPORTANT DES MOYENS DE CREATION DE LIENS ENTRE DES FICHIERS 
PRINCIPAUX ET DES FICHIERS AUXILIAIRES. 

L'inver tlon concerne un mcxiule de s^curite cooperant 
avec un dispositif de traitement de rinformatlon et compor- 
tant des moyens de traitement de Tinfomiation et des 
moyens de stockage de I'information, ces derniers stockant 
plusieurs fichiers. 

Selon I'inventlon, le module de securite comprend: 

- des moyens de creation de lien agences pour creer un 
lien entre au moins un fichier principal (30) et un fichier auxi- 
llaire (31), lo fichier principal ayant un contenu determine 
(33) et etant rendu accessible aux moyens de traitement 
dans les moyens de stockage grace a des donnees de loca- 
lisation (RFC), les moyens de creation de lien associant au 
fichier auxiliaire (31) lesdites donnees de localisation; et 

- des moyens de branchement agences pour mettre a 
disposition des moyens de traitement, lorsque ceux-ci exe- 
cutent une demande d'acces visant a acceder au fichier 
auxiliaire (31), ledit contenu (33) du fichier principal (30) en 
utilisant lesdites donnees de localisation (RFC). 
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Module de securite comportant des moyens de creation de liens entre des fichiers 

prinapaux et des fichiers auxiliaires 

, '' 'Z^ ™u«,ve 4 un module de agenC poor coop^rer 

3 avec un d.sposi« de .raitemenf de rWonnaUon e. con^rtart des moyens de 
^.«ner. de rwo^aUon e. des ok.^, de sU^Kage de rinf=n,»,L. ,es 
■wyww de slockage stockant plusievs fichiers. 

Le tenne ••module de s^- doit Ure pris, soil dans son sens dessique 
Oans lequel il design, un disposM ayan. vocation, dans un r^seau de 
^u™ca«on ou <flnfom«ion. . ^ d.,enu par un organisme supervisan, le 
^ e. a stocker de fa^ prCeg^e das param^tres secrets et fondamentaux 
<Ju reseau teis que des dfe cryptographlques, soil comme d«signant plus 
«nptemem dispositif attribu. , divers usagers du r^seau e. pem»«ant , 
deux d^av^ir acc^s i celui^, ce d^ier dispositi, 6tan. lui aussi 
s|»cep.i«e de d«en,r des param^tres secrets. Ue module de s^ pZ 
prendre la fonro d^un objot portatif du type carte i puce. 

^ \^ '^^^'^ ""^ notamment las cartes i micro^ircuit et plus 

9en*..emen, ies objets portatits do..s de circuits int^nls comportant au moins un 

de^ carte et une ou plusieu,^ mimoires non volatiles, programmables par le 
m,^o^sseur. COS m*moires nc« vola«les permetten. de stocKer des doles 
etdu <»de.Le m.croprocesseur contr^e le transfert des Inftvmations et, le cas 
^^r« memorise ies donn^ * ou tes m pour Ies transmettre 

™^ * eo™»inication. Les 
m^OK-es peuven. «re de technologie EPROM. EEPROM, FeRAM, SRAM ou 

Gr^ a r^voWion de la technologie. la taille de la mSmoire ROM contenant 
•e programme est de plus en plus importante ; ainsi les concepteurs de oe 
P^aramme peuven. inlroduire de plus en plus de fonctions. Certaines de ces 
^^^»e ra,^ directemen, , i.<.ganisa.ion de ,a memoire prograo^ 
^ memo-re. doo. la taille a aussi augment., es, organist hi.rar*lquement en 
^ ««pe„dants, oette organisation est d^e notamment dan, lal^ ,so 
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De nos jours, les cartes peuvent servir a de multiples applications et pour 
cela elles possedent souvent deux ou trois niveaux hierarchiques appelds par 
exemple : CARTE. APPLICATION et SERVICE. A chaque niveau, les informations 
se rapportant S une mSme affectation sont regroupees en fichiers, ces fichiers 
5 comprenant deux niveaux de stockage , d savoir des "REPERTOIRES" et, dans 
chaque repertoire, des informations de m6me nature stockees dans des 
"FICHIERS DE DONNEES ". 

Cette architecture definie en plusieurs niveaux s'elabore gen6raiement lors 
de la personnallsation de la carte, c'est-a-dire avant son utilisation, II est possible 

10 cependant de rajouter en utilisation d'autres repertoires ou d'autres fichiers de 
donn^es , mais ceia depend de la place disponible restant dans la m§moire non 
volatile programmable, Cette memoirs etant de taille limitee, il est important de ne 
pas gaspiller d'emplacement et de definir lors de la personnalisation uniquement la 
place necessaire et suffisante au bon fonctionnement des repertoires et des 

15 fichiers de donnees . 

Un excellent moyen de ne pas perdre de place consiste a ne pas dupliquer 
les informations. Ainsi. il faut §viter que les memes informations utiles a plusieurs 
repertoires soient Sorites de fagon identique dans plusieurs endroits de la 
memoire. Malheureusement, Tarchitecture hierarchisee des repertoires emp6che 

20 de partager un m6me fichier de donnees entre plusieurs r6pertoires. Si deux 
repertoires doivent posseder les memes infonmations. il n'existe d ce jour que la 
solution de creer deux fichiers de donnees comportant ces memes informations a 
rinterieur. La prdsente invention resout ce probleme en evitant la duplication 
d'informations communes, tout en conservant les liens hierarchises entre fichiers 

25 de donnees et repertoires. 

Un autre probldme est celui de la mise ^ jour de fichiers pr6sents en 
plusieurs endroits de la memoire : il faut en effet effectuer les modifications 
n6cessaires en chaque endroit. Outre le fait que cette operation est longue, elle 
peut etre perturb6e par une interruption accidentelle du fonctionnement de la carte 

30 , avec pour consequence probable une mise a jour incomplete de Tensemble de 
ces fichiers , c'est-a-dire une mise S jour de certains fichiers, et pas des autres. La 
coherence entre tous ces fichiers ne serait plus assuree. 

Par ailleurs, la structure en plusieurs niveaux peut penaliser les temps 
tfacces ^ des fichiers de donnees ou repertoires de bas niveaux. En effet, pour 
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a««ndre des .onn.es d'un r.pe«oi™ tfun niveau inf^ur, , fau, dans de 
Par exemple, pour passer d un r^oire * un autre de m«™ niveau i. fau. 

de selection successive est kxird et p^isant en temps. 

La prfeente irwenlkx, vise i rfeoudre ces dtfMrents probteoies elle 
P™cu« un aK.yen .renter ,a duplication en m^noire de donn^ identiques ■ elle 

"«"'««**™«<<'infc»™Uo™pa,,ag6esent,»plusieursfict,,ers;^ 
.0 ^«e la reche^ d-|n..m««ons dans dee ..pertol^ "'^ 

I artjoresoence des fichiers de la m*noire. 

Elle concenrw 4 cet effet un module de s4airit6 du genre d.6 au d^but de 
I expose, qui comprend : 

.5 un fichrr^ * "Nation * lien agenCs pour ^.er un lien entre au molns 

7r "^^^ -y-"' "n contenu 

. rendu accessible aux moyens de .raitemen. dans ies moyens de 
stockaoe grtce d des donnas de localisation, Ies moyens de crtatlon de lien 
assooant au fichier auxiliaire lesdites donn^es de localisation : 

-des moyens de branchement ageno^s pour mettre' i disposition des 
« moye^ de traitement. ,„s,ue ceu.^ executant une demande d^ad 2n^ 
acoeder au fK=bier auxiliaire , ^i. contenu du fichier pnncipal en utilisant lesdites 
donnees de localisation. 

D'autres details et avantages de ia pr6sente invention apparaUront au 
cou^ oe :a aescr.pt,on suivante d une fonne ce r^a.sation prefer. ma.s non 
> limitative, au regard des dessins annexes sur lesquels • 

d.n. ' "^^"^'^ art>orescence de plusieurs niveaux hi^rarchlques 

dans une carte ; ^ 

d^nJ^ ^ ""^^ "~ "Banisation typique de repertoires et de f,ct,iers 
de donnees dans une carte ; 

de "Ti* " * '^'^■'^ fbndamentales 

de fichiers uhlisfe dans I'invention ; 

cr^^i^^^- " ^ '^^'^ "^taillant ies «apes tf une procWue de 
creation de fichier selon rinvention ; et 
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La figure 5 est le schema d'un module de securite auquel est destinee 
rinvention , coop6rant avec un dispositif de traitement de rinfomiation. 

Le dispositif de traitement de Tinformation 51 represents sur la figure 5 
5 cx)mprend de fagon connue en sol un microprocesseur 52 auquel sont relies une 
mSmoire ROM 53, et une mdmoire RAM 54, des moyens 55 pour cooperer, avec 
ou sans contact physique, avec un module de securite 58, et une interface de 
transmission 57 permettant au dispositif de traitement de rinfonfnation de 
communiquer avec un autre dispositif semblable, solt directement, soit au travers 

10 d'un riseau de communication. 

Le dispositif 51 peut en outre §tre equipe de moyens de stockage tels que 
des disquettes ou disques amovrbles ou non, de moyens de saisie (tels qu'un 
clavier et/ou un dispositif de pointage du type souris) et de moyens d'affichage. ces 
diff6rents moyens n'etant pas representes sur la figure 5. 

15 Le dispositif de traitement de rinformation peut etre constitue par tout 

appareil informatique installe sur un site prive ou public et apte a foumir des 
moyens de gestion de rinformation ou de delivrance de divers biens ou services, 
cet appareil etant install^ ^ demeure ou portable. II peut notamment s'agir aussi 
d'un appareil de telecommunications, 

20 Par ailleurs, ie module de securite 58 inclut des moyens de traitement de 

I'infonnation 59, une memoire non volatile 60, une memoire volatile de travail RAM 
64, et des moyens 63 pour cooperer avec le dispositif de traitement de 
rinformation. Ce module est agenc6 pour d6finir, dans la memoire 60, une zone 
secrete 61 dans laquelle des informations une fois enregistrees, sont inaccessibles 

25 depuis rexterieur du module mars seulement accessibies aux moyens de 
traitement 59, et une zone libre 62 qui est accessible depuis Texterieur du module 
pour une lecture et/ou une ecriture d'informations. Cheque zone de la m6moire non 
volatile 60 peut oomprendre une partie non modifiable ROM et une partie 
modifiable EPROM, EEPROM, ou constitute de m6moire RAM du type 'flash", 

30 c"est-d-dire pr6sentant les caracteristiques d'une m6moire EEPROM avec en outre 
des temps d*acc6s identiques a ceux d'une RAM classique. 

En tant que module de securite 58, on pourra notamment utiliser un 
microprocesseur d m6moire non volatile autoprogrammable, tel que decrit dans le 
brevet americain n^ 4.382.279 au nom de la Demanderesse. Comma indiqu6 en 
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-lonne 1, lignes 13-25 de oe brevet le ca«c^ 8u,oprog«™nable de la 
mWe co^espond , le possibim* p«, un p™g«™„e fl dans ce«e 
-en,o.,B, de modifier un au.™ p,o^™ , sih^ 4ga,e,„e« dans ce«e 
en un programme 9i. Bien que les moyens . me«™ en oeuv™ pour ^.iser erne 
autoprogr^matioo puissent varier selon la technique utilise pc, eoncevoir les 
moyens de traitemen. de n,*«na«on 59. on rappelle que, dans le cas oO ces 
moyens de .raite^ent sor* consWufc par un miaoprooesseur associ* i, una 
memo,™ non volaUle e. salon le brave, prtoite. ces moyens peuven, inclure ■ 

-*s mSmoiree tampon de donn*es et d-ad„sses, assoa^es i la m4moi,« • 
H« pragramme tfta«ure dans la mftnoi,,, charge dans celled et 
oontenan, notamment les ins,™ctlc«s pennettam le maintien tfune part de la 
^ * programmation de la m«moi,«. et d'au.re part des donn^es ^ ^ e, 
* aK^Bsses. pendan, un temps sufflsant, ce programme d'icriture pouvant 
toutefou. at« ramplac* par un automate d'^criture a druiits logiques 

Dans une variante. le microprocesseur du module de s6oum 58 est 
tou, du moins compLt^ par des circuits logiques Implant^s dans une 
P^i sem^onducteurs. En effet, de tels d«=uits sont ap.es . etfeCuer des 
Itl ? *-*en.ffication et de signature, g,*e . de «le«™nique 

cSblee. et non micraprogrammee. lis peuvem notarmnen, de type ASIC (de 
ang,a,s . Application Specific Integrated Circuit .). A <f exemple, on peut c«er 
composant de la sod«. SIEMENS comme«.alis* sous la ,«.,enoe SU 4436 
et celu, de la sod«. SGS-THOMSON «x™ne,cialis6 sous la r«S,«nce ST ,335 

Avantageusement. le module de security S8 sera con^u sous fomte 
monolithiquesur une seule puce. 

d^i, rT^^^ *' * "^'^ non volatile autoprogrammable 

sa localisation dans une enceinte inviolable. 



30 



U memoirs non volaflle des cartes est organist en fict,iers qui peuvent 
««. comma rappee prtcWemment, de deux types : repertoire ou f,ct,ier 
elAnentaKe de donnAes. Cheque ficWer ...mentaire comprend un en-t«e et un 
c«ps contenan. des in,c»mations. Le niveau de hi.,ard,isation est p,^ dans 
en^Ste. on y trouve Sgalement les ref&ences du Hchier, l'«at ou phase de vie de 
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la carte, ies conditions d'accds et la taille. En rdgle generale, Ten-tdte contlent 
{'ensemble des informations qui permettent de gerer Ies informations stockees 
dans le corps. Deux ou trois niveaux sont actueliement utilises. En rdfdrence d la 
figure 1 , et en gdn^rai, le niveau superieur est appeld "CARTE", et Ies niveaux 

5 inf6rieurs "APPLICATION" ou "SERVICE". On peut parfaitement envisager des 
cartes avec plus de trois niveaux ; dans Texemple cite, trois niveaux sont decrits. 

A titre d'exemple, une mSme carte peut etre utilisde pour diverses 
applications telles que : la banque, la municipalite, le dossier medical, le 
radiotelephone cellulaire, qui sont representees par des repertoires de niveau 

10 APPLICATION. Dans Tapplication municipale, on trouve des parties telles que Ies 
transport publics. Tacces a la piscine et a la bibliotheque, le paiement du 
stationnement, qui sont representees par des repertoires de niveau SERVICE. 

La figure 2 illustre un exemple des liens hierarchises entre des fichiers dans 
la memoire programmable d'une carte. Le repertoire CARTE contient deux 

15 repertoires APPLICATION 1 et 2 et le fichier elementaire C1. Le repertoire 
APPLICATION 1 contient deux repertoires SERVICE A1-S1 et A1-S2 et le fichier 
elementaire A1-1. Le repertoire SERVICE A1-S2 possede un seul fichier 
el6mentaire de donndes : A1S1-1. Le repertoire APPLICATION 2 poss6de deux 
repertoires SERVICE A2-S1 et A2-S2, Le repertoire SERVICE A2-S1 poss6de 

20 deux fichiers eiementaires de donndes : A2S1-1 et A2S1-2. Le repertoire SERVICE 
A2-S2 possede un fichier elementaire de donnees : A2S2-1. Tous ces fichiers 
occupent une place non negligeable dans la memoire limitee de la carte, il est 
done important d'optimiser roccupation memoire et d'eviter de dupliquer Ies memes 
informations dans plusieurs emplacements differents. 

25 Dans certains cas, Ies memes informations sont utilisees par deux 

repertoires differents. Par exemple, Ies coordonnees bancaires d'un individu 
porteur d'une carte : nom et adresse du porteur, nom et coordonnees de la 
banque. num6ro de compte. information sur le credit ...etc. peuvent etre stockees 
dans un fichier elementaire, Indus dans le repertoire correspondent e Papplication 

30 t>ancaire, par exemple : le fichier elementaire A1-1 dans le repertoire 
APPLICATION 1 , decrit dans la figure 2. 

La carte peut aussi servir de carte-ville ; cette application est geree par le 
repertoire APPLICATION 2. Elle permet notamment de payer Ies transports en 
commiin, d*acceder e la bibliotheque municipale et a certaines activites culturelles 



BNSDOCID: <FR 2765362A1_I_:> 



10 



2765362 

7 

payantes (theatre. cin6ma...). Ces services sont geres par ies deux r6pertoires 
SERVICE A2-S1 et A2-S2. hi6rarchlquement dependants du repertoire 
APPLICATION 2. Lorsque la carte sert de moyen de paiement, pour payer par 
exemple Ies trajets effectuds dans Ies transports en commun. I'argent est d6bit§ 
directement sur le compte bancaire dont ies coordonn6es sont pr6cis6es dans le 
fichier eidmentaire A1-1. II faut done rendre accessible depuis le repertoire 
SERVICE A2-S1 du repertoire APPLICATION 2, Ies informations du fichier 
eiementalre A1-1 de APPLICATION 1. Cet acces est symbolise par la fieche sur la 
figure 2. La solution consistent d reproduire Ies donnees n'est pas satisfaisante. 

Un autre exemple conceme Ies cles secretes et Ies codes confidentiels : 
leurs valeurs peuvent 6tre identiques lors de faeces a diff6rentes repertoires qui 
ne sont pas hierarehiquement dependants. Le probieme est Important si des cl6s 
de type RSA ( des inventeurs Rivest, Shamir et Adieman) stoekees sur plus de 
1024 bits sont utilisees. Un dernier exemple conceme Ies fichiers eiementaires de 
15 ratification : ces fichiers eiementaires servent e memoriser Ies bonnes ou 
mauvaises presentations de cles ou codes. Le regroupement de plusieurs fichiers 
eiementaires de ratification con-espondant a des eies differentes pemiet de gagner 
de la place et d'aceroTtre la securite. 

Une fa9on de realiser invention oonsiste a creer et gerer des fichiers dits 
20 Tien" dont le corps est confondu avec celui d'autr«s fichiers. L'invention eonsiste e 
pouvoir partager un meme corps de fichier entre plusieurs fichiers. Ced peut §tre 
realise en indiquant. soit dans ren-t6te du fichier. soit dans son corps. I'adresse oil 
se situent effectivement Ies donnees. 

Sur la figure 3. sont repr6sentes deux fichiers. e savoir un fichier-cible 30 et 
25 un fichier-lien 31 . La description qui suit conceme aussi bien le eas oCi ces fichiers 
sont des fichiers de donnees et ceiui ou ils representent des repertoires. Ces 
repertoires contiennent soit une artx)rBseence de sous-repertoires donnant acces 
d des fichiers de donn6es. soit des fichiers de donnees qui leur sont directement 
rattaches. soit Ies deux. Le temie « donnees » regroupe a la fois des donnees non 
30 executables et des donnees exeeutables ou programmes. 

Le fichier-cible 30 est organise, dans cet exemple. en deux parties 
comprenant un en-tete 32 et un corps 33. L'en-tete 32 inelut un premier groupe de 
parametres connus en eux-memes, a savoir : 
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-un type, qui indique si ie fichier est un repertoire ou bien un fichier de 
donndes ; 

-un identifiant qui designe Ie fichier au sein d'un repertoire qui Ie contient ; il 
s'agit par exemple d'un nom ou d'un numero ; et 
5 -des conditions d'acces qui donnent une liste de droits d'accSs d ce fichier 

determine, pour tout usager : eties precisent par exemple si Ie fichier est 
accessible ou non en lecture ou §criture ; de fa^on connue en sol. la 
d^livrance de ces droits peut §tre subordonnde d la presentation de cles ou 
mots de passe. 

10 

L'en-tete 32 inclut un second groupe de parametres qui sont sp6cifiques ^ 
rinvention, a savoir : 

-un paramdtre <Lien> qui peut prendre deux valeurs : soit la valeur 1. qui 
indique que ce fichier est un fichier-iien soit la valeur 0 qui indique qu'il n'est 

15 pas un fichier-lien ; ici, ce parametre a la valeur 0 ; 

-un parametre >Lien< qui peut prendre deux valeurs : soit la valeur 1 , qui 
indique que ce fichier est un fichler-cible, soit la valeur 0 qui indique qu'il 
n'est pas un fichier-cible ; ici, ce param6tre a la valeur 1 ; 
-un parametre A-Lien qui peut prendre deux valeurs : soit la valeur 1 , qui 

20 indique que ce fichier peut etre Ii6 a un fichier-lien , soit la valeur 0 qui Ten 

empdche ; et 

-un parametre CA-Lien qui d6finit des conditions de creation que I'usager 
devra respecter lorsqu'il voudra cr6er un lien entre ce fichier et un fichier-^. 
lien : elles pourront par exemple definir des des ou mots de passe ^ 
25 presenter par I'usager. 

Uen-tete 32 comporte enfin une r6f6rence RC indiquant au microprocesseur 
de la carte une valeur binaire d'une adresse memoire RC a partir de laquelle est 
stocke Ie corps 33 pr6cit6. 
30 Dans une variante. Ie corps 33 est stocke en memoire immediatement ^ la 

suite de I'en-tete 32, de sorte que la mention de la reference RC n'est pas 
n^cessaire. 

Par ailleurs. si Ie fichier cible 30 est du type « repertoire » , Ie corps 33 
contient soit une art)orescence de sous-repertoires donnant acces S des fichiers 
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de donndes. soit des fichiers de donnas qui iui sont directement rattadiSs, soit 
ies deux ; 

Si au contraire le fichier-cible 30 est du type « fichier de donndes », le corps 
33 contient un ensemble de donnees directement accessibles pour lecture ou 
modification, ou exdcutables par le microprocesseur de la carte . 

En variante . I'organisation du fichier-cible 30 pounra dtre diffdrente de celle 
en deux parties (en-t6te et corps) pr6sentee sur la figure 3. Ainsi par example , Ies 
paramdtres de I'en-tdte 32 pourront fitre repartis en des endroits sp^ifiques du 
corps. 

Quant au fichier-llen 31 , il ne comprend qu'une seule partie, a savoir un en- 
t§te qui pr6sente la meme structure que celui 32 du fichier-cible 30, mais a un 
contenu qui en differe de la fagon suivante : 

-s'agissant d'un fichier-lien . et non d'un fichier-cible. Ies paramdtres A-Lien 
et CA-Lien ne sont en g^^rai pas utilises, sauf dans le cas particulier d^crit plus 
loin ; 

-par ailleurs, la « reference » n est pas celle relative d un dventuel a>rps 
rattach6 au fichier-lien , mais une r6f6rence RFC pr^dsant la localisation en 
memoire d'un fichier-cible ainsi 116 d ce fichier-lien. Dans cet exemple , c'est le 
fichier-cible 30. La reference RFC est soit de preference « physique » et constitute 
par une valeur binaire d'une adresse mdmoire a partir de laquelle est stodce le 
fichier-cible 32 prddtt. soit en variante « logique » et constituee par un chemin 
d'accds pr^sant Ies identifiants d'un ou plusieurs repertoires d partir desquels le 
fichier-cible 32 est accessible. 

Dans le cas tr6s particulier d'une gestion dynamique de la memoire de la 
carte, celle-d peut §tre r§-organis6e par le microprxx:esseur afin d'optimiser 
I'occupation de la memoire. L'emplacement des fichiers peut done fluctuer, ainsi 
par consequent que leurs adresses d'implantatlon. Dans ce cas, seule la r6f6rence 
logique du fichier-cible est facilement utilisable car Ies adresses physiques 
risquent de constamment changer. En prenant comme exemple le cas 6voqu6 
precedemment, la reference logique est : [CARTE -» APPLICATION 1 -♦ Fichier de 
donnees A1-1]. 

II apparait done qu'un fichier-lien est d6pourvu de corps, mais est lit d un 
fichier-cible determine, dont le corps sera ainsi mis e disposition du fichier-lien. 
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On notera que, dans un cas particulier, un second fichier-lien, different du 
fichier-lien 31, pounrait 6tre non pas directement a un fichier-clble , mais par 
exemple au fichier-lien 31 . La situation serait alors la suivante : 

-la rdfdrence contenue dans le second fichieNien serait celle du fichier-lien 

31 ; 

-le parametre CA-Lien serait avantageusement utilise dans I'en-t6te du 
premier fichier-lien pour controler les conditions de creation du second fichier-lien . 



En fonctionnement. lors de la selection d*un fichier par rusager , un 
10 programme du microprocesseur lit son en-tete et teste son parametre <Lien>. S1I 
est egal d 0, le fonctionnement est conforme a Tart anterieur : le corps 
estdirectement rattache a cet en-tdte. 

Si <Uen> est 6gal a 1, le fichier est un fichier-lien. Le programme lit en 
consequence la reference RFC de ce fichier-lien precisant Tadresse ou le chemin 
15 d'acces d'un fichier-cible contenant un corps indirectement rattache a Ten-tfite du 
fichier-lien. Avant de mettre a disposition de I'usager ou du microprocesseur le 
contenu du corps du fichier-cible , le programme effectue les verifications 
suivantes, en consultant les en-tetes respectlfs du fichier-lien et du fichier-clble : 

-lors de la creation du fichier-lien. il verifie que le type du fichier-cible 
20 identifie est Identique d celui du fichier-lien ; dans la negative, la procedure 
d'acc^s au fichier-lien est interrompue ; 

-lors de cheque acces au fichier-cible, ii verifie le respect des conditions 
d*acces selon une procedure qui sera precisee plus loin. 

25 Ces verifications etant effectuees. le programme poursuit sa proc6dure 

d'accds au contenu du fichler-lien.Si la taille du corps du fichier-cible est « z6ro 
octet » , c'est-^-dire s'il ne contient rien, le programme s'interrompt et la carte 
renvoie un message d'erreur. Sinon, le programme recherche les informations 
contenues dans ce corps, d partir de Tadresse RC. En reprenant Texemple de la 

30 figure 2, on suppose que le fichier A1-1 du repertoire de Tapplication 1 a ete cree 
sous forme de fichier^^ible, et que les fichiers A2S1-1, A2S1-2. A2S2-1 des 
repertoires service A2-S1 et A2-S2 ont ete crees sous forme de fichiers-lien. En 
consequence, la selection tfun fichier-lien tel que A2S1-1 donnera accds au 
contenu du fichier-dble A1-1. 
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Les conditions d'accds au cx)rps du fichier-Cible, definles dans Ten-tete de 
celui-ci, doivent dans tous les cas etre respect^es, lors de TexScution d'un lien 
entre fichier-lien et fichier-cible . Plusieurs strategies sont possibles. La plus 
5 simple consiste a obeir aux conditions d'acces definies dans I'en-tete du fichier- 
Cible :ainsi Taccfes des infomnations dans le fichier-Cibie via le fichier-lien n'est 
accord^ que si les conditions d*acces du fichier-Cible sont respect^es. 

Une autre strategie consiste a prendre en compte les conditions d'acc6s du 
fichier-Cible lors de la creation du fichier-lien. II faut alors verifier que les 
10 conditions d'accfes inscrites dans ren-t6te du fichier-lien incluent toutes les 
conditions d'acces du fichier-Cible auquel il va etre lie. 

Une troisi^me strat6gie est applicable lorsque les conditions d'accds 
s'expriment sous la forme d'une valeur binaire : elle consiste a cumuler les deux 
conditions d'accds. Concr6tement, cette operation peut etre rdalisee en effectuant 
15 un ET logique entre les deux valours. Uacces des informations dans le fichier- 
Cible via le fichier-lien n'est accorde que si, a la fois, les conditions d'accds des 
fichlers-Clble et lien sont respectees. 

A travers ces diff^rentes strategies, le lecteur comprend que Tobjectif, au 
niveau du contrdle d'acces, consiste a proscrire toute possibilite de contoumer les 
20 conditions tfacc^s tfun fichier en le liant ^ un fichier qui possede des conditions 
d'acc6s plus favorables. D'autres strategies, connues de I'homme du m§tier. 
pourront dtre utilisees pour assurer la sdcurite d'accds. 

Un perfectionnement important concemant la securite consiste d utiliser le 
param6tre A-Lien d'un fichier-cible pour I'empecher d'etre lie d un autre fichier . Si 
25 la valeur de ce parametre est "1". lors de la creation d'un fichier-lien rattach6 a ce 
fichier-cible , ['operation est menee a bien et le contenu du corps du fichier-Cible 
est bien accessible par le fichier-lien. Si en revanche la valeur de ce champ est 
"Ot\ ce fichierKable ne peut §tre lie a aucun autre. Lors d'une tentative de creation 
tfun fichier-lien d6slgnant un fichier dont le champ A-Lien egal a "0". Toperation est 
30 refusee et la carte rend un message d'erreur 

Un probl6me se pose lors de Teffacement. c'est-a-dire de la suppression de 
fichiers Lien/Cible. SI un fichier-Cible est efface, I'accds par des fichiers-Liens aux 
informations qu'il contenait n'est plus possible. Les consequences d'un tet 
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effacement ne sont done pas uniquement limitees au repertoire qui contenait ce 
fichier, mais peuvent se rSpercuter dans d'autres repertoires. La solution consiste 
soit a interdire reffacement du fichier-Cible auquel est rattachd un ou plusieurs 
fichiers-Lien . soit d avertir Tutilisateur de la carte que certains fichiers ne sont plus 

5 operationnels apres cat effacement. Un premiere methode consiste done d tester 
la valeur >Lien<. Si cette valeur est 1, le fichier que ron est en train d'effacer est 
un fichier-Cible. Uoperation est alors soit interdite , soit menee a bien mais avec un 
avertissement ; dans ce dernier cas, le terminal de commande de la carte doit 
effacer tous les fichiers-Lien lies au fichier-cible efface, 

10 Pour effacer un fichier-Cible sans perturt)er le reste de la memoire, il faut 

done prealablement effacer tous les fichiers-Lien qui lui sont rattach6s. Lorsque le 
dernier fichier-Lien est efface, I'indicateur >Lien< prend la valeur "0" : il ne s'agit 
done plus rfun fichier-Cible. Un simple indicateur binaire n'est done pas suffisant 
pour comptabiliser le nombre de fichiers-Lien sans devoir balayer chaque fois 

15 toute la m6moire non volatile de la carte . Une solution consiste ^ pr6voir un 
compteur Cp-Lien a la place du parametre >Lien<. Avantageusement, ce compteur 
est de 8 bits, ce qui autorise Texistence de 255 fichiers-Liens au maximum : ce 
nombre paraTt largement sufTisant pour des applications courantes. Ce compteur 
est incorpor§ dans I'en-tdte du fichier-cible . 

20 Lors de la creation du fichier-cible. le compteur Cp-Lien est mis ^ "00". A 

chaque nouvelle creation d"un fichier-Lien qui est rattach6 au fiehier-cible . le 
compbsur est increments. A chaque effacement d'un fichier-Lien qui lui est 
rattache, le compteur est deeremente. Avantageusement, lors de la selection de ce 
fichier-cible, la valeur du compteur peut etre emise avec les autres information 

25 d'en-t6te : Tutilisateur peut ainsi connaitre le nombre de fichiers-Lien rattach6s au 
fichier-cible selectionnd. 

Pour resoudre le probleme de reffacement d'un fichier-Cible de fagon plus 
adroite, le programme de la carte est equipe d'une commande, aetivable de 
30 rexterieur de la carte, permettant d'echanger les statuts respectifs « lien » et 
4( cible * de deux fichiers. Ainsi. un fichier-Cible devenu un fichier-Lien peut 6tre 
efface sans consequence pour les autres fichiers-Lien. Le contenu du nouveau 
fichier-Cible est alors constitue par celui de I'ancien fichier-cible . Cette operation 
est partieulierement facile lorsque les corps de fichiers sont physiquement s6par6s 
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des en^etes. Pour des raisons de s6curit6. rex6cutlon de cette commande est 
soumise a la v6rification des conditions d'accds d6finies dans l'en-t§te de l ancien 
fichier-cible. et dventueilement a la verification des conditions de cr^ion de liens 
entre fichiers, ddfinies par le param6tre CA-Lien dans le repertoire du nouveau 
5 fichier-dble . Lots de I'exdcution de cette commande d'6change, la valeur du 
compteur CP-Lien de I'anden fichier-Cible est m6moris6e dans le compteur CP- 
Lien du nouveau fichier-Cible. 

La figure 4 illustre un proc6d6 de creation d'un fichier, qu'il s'agisse d'un 
10 fichier-lien ou non. II inclut. outre des etapes sp^cifiques d I'invention et relatives 
au fichier-llen . certaines 6tapes connues en elles-m^mes et relatives S la creation 
de tout fichler. quelle que solt sa nature. A r§tape 1 , un ordre de cr6ation de fichier 
est re^u par la carte, accompagne de donnees de creation : ces donnas 
definissent notamment le type et I'identifiant du fichier d cr§er et. s'il s'agit d'un 

15 fichier-lien , la reference RFC (figure 3) d'un fichier-cible auquel 11 doit 6tre lie. 

Ensuite, le syst6me d'exploitatlon de la carte v6rifie que ia creation d'un 
nouveau fichier est possible dans le repertoire actual, appeld aussi "courant" 
(etape 2). En effet. ia creation d'un nouveau fichier est dventuellement soumise ^ 
la bonne presentation prealable de cl6s ddfinies par ies conditions d'accds de I'en- 

20 tete du repertoire courant Puis, on v6rifie qu'il reste suffisamment de m6moire 
dans le repertoire courant pour contenir le nouveau fichier (etape 3). Si un de ces 
tests est n6gatif. I'ordre de creation est inten-ompu (etape 13). et la carte renvoie 
alors un message correspondant a I'origine de I'arret. 

Le systeme d'expioitation teste ensuite s'il s'agit de la creation d'un fichier 

25 nonnal ou de la creation d'un fichier-Lien (etape 4). Une difference importante 
entre un fichier nonmal et un fichier-lien, et sur taquelle peut porter le test reside 
dans Ies donnees de creation, et principalement dans rindication precise de la 
localisation du fichier-Cible (adresse physique ou logique). Si ce n'est pas un 
fichier-Lien, le programme saute directement e I'etape 12 decrite ci-apres. Dans le 

30 cas contraire, Ies informations correspondant au fichier-Cible designe sont 
recherchees et analysees e retape 5 ; puis le systeme d'expioitation effectue un 
certain nombre de tests pour s'assurer que le lien entrele fichier-cible designe et le 
fichier-lien e creer est possible. 
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Tout d*abord, on verifie d I'aide des donndes de creation que le fichier-Cible 
existe bien (6tape 6). Si par contre, ces donnees ne correspondent S aucun fichier, 
('operation de creation est interrompue et la carte envoie un message d'erreur 
(dtape 13). A Tetape 7, le paramdtre A«Lten du fichier Cible localise est testd. Si 

5 sa valeur est "1", l'op6ration peut §tre menee a bien, Sinon, le fichier-Cible ne peut 
6tre M ik aucun autre. L'op6ration de creation est alors interrompue et la carte 
envoie un message d'en^eur. A r6tape 8, le systdme Sexploitation teste si les 
eventuelles cles d6finies dans les conditions de creation du fichier-Lien, c'est d 
dire d«§finies par le parametre CA-Lien du fichier-Cible, ont et§ prealablement 

10 present6es. Si ce n'est pas le cas, Toperation de creation est interrompue. 

A retape 9, le systeme d'exploitation de la carte verifie que les types de 
fichiers et les conditions d'acces aux informations sont compatibles. Pour cela, le 
parametre TYPE du fichier-Cible est compar§ a celui transmis dans les donn6es 
de cr6ation. Si les valeurs sont differentes, ou du moins incompatibles, comme par 

15 exemple dans le cas d'un ordre de creation visant a fa ire un lien entre un fichier de 
donnees et un repertoire, ou un lien entre un fichier de donnees de type "public" 
et un fichier de donnees de type "secret", alors I'operation de creation est 
interrompue et la carte envoie un message d'erreur. Ce test est facultatif car une 
autre solution consiste i forcer les donnees regues pour le fichier-Lien d crSer, a la 

20 mSme valeur que celles du fichier Cible designe : la compatibilite est dans ce cas 
certaine. 

Enfin, un demier test effectud porte sur les conditions d*accds aux 
informations contenues dans le fichier-Cible (etapelO). II s'agit d'eviter de 
contoumer les conditions d'acces du fichier-Cible par un fichier-Lien qui 

25 possederait des conditions d'acces plus favorables. Une des strategies ddcrites 
prece<iemment consiste a interdire la creation d'un fichier-Lien poss6dant des 
conditions rfacces moins restrictives que celles du fichier-Cible : Topdration de 
creation est alors interrompue et la carte envoie un message d'erreur (etape 1 3). 
Une autre strategie consiste ^ amenager, et done modifier, des conditions d'acces 

30 trop favorables du fichier-lien pour les rendre au moins aussi restrictives que celles 
du ficliier-Cible. Dans ce cas, le test de retape tO devient une operation de calcul 
avec modification, si besoin, des conditions d'acces transmises dans la 
commande. 
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Une fois les stapes de test franchies. la creation du fichier-Lien peut 
intervenir. A I'etape 11, I'ei>t6te du fichier-Cible est mise a jour. Cela conceme 
prindpaiement le param§tre >Lien< ou Cp-Lien. S'll s'agit du paramdtre >Ljen<, , 
le programme v6rifie qu'il possdde la valeur a "1", ou sinon le met d cette valeur. 
S'il s'agit au contraire du compteur Cp-Lien. . celui-ci est increments d'une unit6. 

Enfin d I'^pe 12, un nouveau fichier est effectivement cr^, et les valeurs 
des paramdtres d'en-tdte de oe fichier sont dStemiinees en m6moire de travail a 
partir des donn^ de o^dation. Ces valeurs sont ecrites en m6moire 
programmable non volatile. Si c'est un fichier-Lien qui est cree, une reference liee 
S la localisation du fichier-Cible (adresse physique ou logique) est ecrite. Une fois 
toutes ces etapes franchies, la carte rend un message d'etat correct et le fichier 
nouvellement cr66 est operationnel. 

Le cas de la creation d'un fichier-Cible ne sera pas detaille, puisque. lors de 
sa cr6ation, ce fichier est analogue a un fichier classique. Ce n'est qu'au moment 
ou il est lie d un fichier-lien qu'il devient un fichier-cible effectif. 

Une application particulidrement int^essante de I'invention et relative aux 
repertoires-lien est celle ou un repertoire porte-monnaie 6lectronique est utilise par 
la carte pour penmettre des paiements. Ce repertoire contient des fichiers 
etementaires contenant des cl6s. des zones d6bit-credits, des zones de validation 
de mot de passe, etc... Un tel r6pertoire peut etre utilise dans diverges applications 
(transport, restaurant, centrale d-achats) : chacune d'elles doit done contenir un 
repertoire-lien lie au repertoire porte-monnaie eiectronique, lequel devient alors un 
repertoire-cible. 
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REVENDICATIONS 

1 . Module de security agence pour coopSrer avec un dispositif de traitement 
5 de rinformation et comportant des moyens de traitement de rinfonmation et des 

moyens de stockage de rinformation, las moyens de stockage stockant plusieurs 
fichiers . caracterise en ce qu'il comprend : 

-des moyens de creation de lien agences pour creer un lien entre au moins 
un fichier principal (30) et un fichier auxiliaire (31), le fichier principal ayant un 
10 contenu determine (33) et etant rendu accessible aux moyens de traitement dans 
les moyens de stockage grace d des donn^es de localisation (RFC), les moyens 
de creation de lien associant au fichier auxiliaire (31) lesdites donnees de 
localisation ; 

<les moyens de branchement agences pour mettre a disposition des 
15 moyens de traitement. lorsque ceux-ci executent une demande d'accds visant a 
acceder au fichier auxiliaire (31), ledit contenu (33) du fichier principal (30) en 
utilisant lesdites donnees de localisation (RFC). 

2. Module de securite selon la revendication 1, dans lequel le fichier 
20 auxiliaire (31) contient un parametre (<lien>) indiquant qu1l contient des donnees 

de localisation d'un fichier principal (30). 

3. Module de securite selon la revendication 1, dans lequel le fichier 
principal (30) contient un parametre (>lien<) indiquant que ses donnees de 

25 localisation (RFC) sont associ^es a au moins un fichier auxiliaire (31). 

4. Module de sdcuritS selon la revendication 3, dans lequel ledit parametre 
(>lien<) est une valeur d'un compteur (Cp-Lien) agence pour compter un nombre 
de fichiers auxiliaires.(31) qui sont li^s a ce fichier principal (30). 

30 

5. Module de securite selon la revendication 1, dans lequel le fichier 
principal (30) contient un parametre (A-Lien) indiquant si la mise ^ disposition de 
son a:>ntenu lors d'une demande d'acces au fichier auxiliaire (31) est autorisee ou 
non. 
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6. Module de s6curit6 selon la revendicatlon 1. dans lequel le fichier 
principal (30) contient un paramdtre (CA-Llen) d6flnlssant des conditions de 
creation d respecter par les moyens de traitement lors de la creation d'un lien avec 
5 un fichier auxiliaire (31 ) determine. 
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